PATENTS 
15311-2207 
200308268-1 



REMARKS 

Reconsideration and further examination of the application are respectfully re- 
quested. All rejections and objections are traversed. 

Claims 1-37 stand rejected under 35 U.S.C. §103 as being obvious over U.S. Pat- 
ent No. 5,634,122 issued to Loucks et al. (hereafter "Loucks") in view of U.S. Patent No. 
5,506,961 to Carlson et al. ("Carlson"). Applicant respectfully disagrees that Loucks and 
Carlson render the claimed invention obvious. 

Claim 1 recites: 

"A computerized data file system, comprising:" 

"a first process that maintains a data file stored in a computer-readable 
memory", and 

"a second process that generates a first message requesting that said sec- 
ond process be granted by said first process a plurality of tokens required for 
said second process to modify at least one characteristic of said file stored in said 
computer-readable memory", 

"said first process generating a second message, in response to said first 
message, that grants said tokens to said second process if said tokens are avail- 
able for grant to said second process". 

The Office Action acknowledges that Loucks "does not clearly teach the first 
process a plurality of tokens required for said second process to modify at least one char- 
acteristic of said file stored in said computer-readable memory." Office Action, p. 3. 
The Office Action goes on, however, to assert that "Carlson teaches a system including 
server device and client device and determining the type of tokens and the number of to- 
kens sent out and distribution of token types." Office Action, p. 3. In support of this, the 
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Office Action cites to Col. 4, lines 5-10, Col. 8, lines 6-10 and Col. 9, lines 2-5 and 16-25 
of Carlson. 

As show herein, Carlson too fails to teach or suggest "a second process" that gen- 
erates a "first message" requesting a "plurality of tokens" so that the second process may 
modify at least one characteristic of a file. In particular, Carlson, at Col. 4, lines 1-10, 
which is one of the excerpts relied on by the Office Action, states as follows: 

If the system authorizer determines that the client device should be allowed to ac- 
cess the information on the subject server device, it then sends a token to the 
server device and a copy of the same token to the client device. Depending on se- 
curity needs, the token may or may not be encrypted. It is also possible that the 
requisite information resides on more than one server device or that more than 
one client device requires the information. The system authorizer handles multi- 
ple device situations by dispatching multiple tokens and token copies. 

In other words, with Carlson, the client device requests only one, single token. This is 
confirmed by Carlson's use of the terms "a token" and "the token" in the above excerpt. 
The reference to multiple tokens by Carlson has to do, not with a single client requesting 
multiple tokens, but with the situation where there are multiple clients or multiple serv- 
ers. Carlson acknowledges that, if there are multiple clients, then multiple tokens will be 
dispatched; one to each client . This excerpt provides no teaching or suggestion that a cli- 
ent device, within a single message, requests multiple tokens. To the contrary, this ex- 
cerpt confirms that, at all times, Carlson's client device only requests a single token at a 
time. 

This is confirmed in the other parts of Carlson cited by the Office Action. For ex- 
ample, at Col. 8, line 63 to Col. 9, line 5, Carlson states that: 
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The last type of token, the generic token (shown as choice 820), is used to 
allow free access to the information on a particular server device. In our multi- 
media example, this may occur if system authorizer mechanism 112 deter- 
mines that client devices other than PWS 380 will likely be in need of the in- 
formation stored on optical storage device 340 and that such access should be 
freely granted. Once again, system authorizer mechanism 1 12 could determine 
that these conditions exist for more than just optical storage device 340 and send 
out multiple generic tokens. 

That is, with Carlson, when multiple clients request information, then multiple tokens are 
sent; one to each client. Once again, there is no teaching or suggestion by Carlson that a 
single client device makes a request for multiple tokens. Instead, according to Carlson, 
each client makes a request for a single token. 

In fact, Carlson actually teaches away from the present invention, because his cli- 
ent device is precluded from requesting more than one token. More specifically, Carlson 
illustrates the format of his request message 400 at Fig. 4. The request message 400 only 
has room to request a single token, namely the one and only Server Token field 440. 
Carlson confirms that his clients can only request one token when he states that "Field 
440 contains the actual token itself. Carlson, Col. 9, lines 27-28. Thus, Carlson's re- 
quest message 400 is, by definition, limited to requesting only one token, not multiple 
tokens. 

Because Carlson fails to teach or suggest a system whereby a process generates a 
message requesting a plurality of tokens , the rejection of claim 1 based on Carlson should 
be withdrawn. The rejection of claims 2-5 and 38, which depend from claim 1, should 
also be withdrawn. For these same reasons, the rejection of independent claims 14, 27, 
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and 30, and the rejection of the claims that depend from them, claims 15-18, 28-29, 31- 
35, 39 and 40 should also be withdrawn. 

Independent claims 6, 11,19, 21, 33 and 36 recite requests for the "grant of a set 
of tokens". The Office Action at p. 5 asserts that Carlson, in the excerpts previously dis- 
cussed, provides such a teaching. As set forth above, Carlson fails to teach or suggest a 
client device that can request a set of tokens. Instead, Carlson only teaches a request for 
a single token. Because Carlson fails to teach or suggest a client that requests more than 
one token, the rejection of these independent claims, and the claims that depend from 
them, should be withdrawn. 

Independent claim 20 recites "a first message that grants a set of tokens". Carlson 
fails to provide such a teaching or suggestion. In particular, Carlson's open message 500, 
which is shown at Fig. 5, only transmits a single token, via the one "Server Copy Token" 
field 525. Carlson provides no teaching or suggestion of a message that grants a set of 
tokens. Accordingly, the rejection of independent claim 20 should also be withdrawn. 

Applicant submits that the application is in condition for allowance and early fa- 
vorable action is requested. 

It is believed that no extensions of time or fees are required, beyond those that 
may otherwise be provided for in documents accompanying this paper. However, in the 
event that additional extensions of time are necessary to allow consideration of this paper, 
such extensions are hereby petitioned under 37 C.F.R. §1.1 36(a), and any fees required 
(including fees for net addition of claims) are hereby authorized to be charged to Hewlett- 
Packard Development Company's deposit account no. 08-2025. 
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